It may be desirable for a client of a vendor, such as a law firm, to track work done for the client by the vendor. In particular, it may be useful for a number of clients to use a common service to track work done by a number of different vendors, in a model where each client pays to use the service to track work done for the client by one or more vendors.
Such a service may be implemented using a client-centric data model, in which the service provides a separate database or instance of the service for each client's work. For a particular client, the client's database contains information about the client's projects, and each of the vendors engaged to work on these projects. For example, a client's database may contain information such as the following for two or more different vendors: the vendor's name, contact information for the vendor, and user information for the vendor. Much or possibly all of the information in a client's database might have to be manually entered by the client.
This client-centric data model has several possible disadvantages. As one example, where a particular vendor is engaged to work for three different clients, the vendor information must be separately entered (bye either the vendor or the applicable client) in each database or instance of the service. Such data entry is redundant, and can create inconsistencies between the vendor information stored for the same vendor in different client databases, such as where (i) the information in one of the client's databases or instances of the service might have been entered incorrectly; (ii) one of the client's information about the vendor may have been inaccurate or out-of-date information, and such inaccurate information was therefore entered into the client's database or instance of the service; or (iii) information may have been initially entered correctly, but later becomes out-of-date (e.g., an attorney at a law firm leaves the law firm, and the law firm remembers to delete or deactivate the attorney in client #1's database but not in other client's databases). Moreover, where the vendor data stored for the same vendor in different client databases or instances of the service is inconsistent, the merging of this vendor with another vendor may require significant manual effort to reflect the merger in each client database containing vendor information for either of the two vendors.
Also, where a single vendor user is designated to maintain data for two or more different clients, the user may be required to maintain a different set of user credentials for each of these multiple clients and log on to the service separately to maintain data for each of the multiple clients. Such requirements may impose significant burdens on vendor users.
Alternatively, to avoid the disadvantages of a client-centric data model, a service could be implemented using a client-commingled data model, in which the service combines the information about multiple clients' projects and their vendors' information in one database. Using the client-commingled data model, a single instance of a particular vendor's information could be maintained for all clients that are using the service, so that the particular vendor's information would not have to be redundantly entered for multiple clients, and the particular vendor's information would be consistent for all clients who are using the service.
This client-commingled data model, however, also has several possible disadvantages. As one example, if clients' projects contain potential confidential data, the client-commingled data model creates potential security weaknesses. The ability to ensure that only client #1 users see information about client #1 projects (or in other words that other clients' users cannot see information about client #1 projects) is dependant on the code comprising the client-commingled data model not having any errors or bugs that could allow other clients' users (or unauthorized vendor users) to see information about client #1's projects, or accidentally cause clients' information to be commingled. Since all code has varying amounts bugs and errors, this model does not offer the security of other models, such as a model that maintains information about each client's project in a separate database and does not allow cross-database queries and routines. Scalability can be another potential disadvantage of the client-commingled data model. For example, as the number of clients, client projects, and vendors increases in a single database, the processing speed of the service may be degraded.
In view of the disadvantages of the client-centric data model and the client-commingled data model discussed above, an improved data model that overcame some or all of these disadvantages would have significant utility.